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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document specifies the content of the stage one requirement for realisation of VHE. 

Virtual Home Environment (VHE) is defined as a concept for personal service environment (PSE) portability across 
network boundaries and between terminals. The concept of the VHE is such that users are consistently presented with 
the same personalised features, User Interface customisation and services in whatever network and whatever terminal 
(within the capabilities of the terminal and the network), wherever the user may be located. 

A key feature to support VHE is the ability to build services using a standardised application interface. 

Requirements not applicable for R99 will be explicitly indicated. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

2.1 Normative references 

[1] GSM 01.04 (ETR 350): "Digital cellular telecommunication system (Phase 2+); Abbreviations and 

acronyms". 

[2] GSM 02.57: "Digital cellular telecommunication system (Phase 2+); Mobile Station Application 

Execution Environment (MExE); Service description". 

[3] GSM 02.78: "Digital cellular telecommunication system (Phase 2+); Customised Applications for 

Mobile network Enhanced Logic (CAMEL); Service definition - Stage 1". 

[4] GSM 11.14: "Digital cellular telecommunication system (Phase 2+); Specification of the SIM 

Application Toolkit for the Subscriber Identity Module - Mobile Equipment; (SIM - ME) 
interface". 

[5] 3G TS 22.01: "Universal Mobile Telecommunications System (UMTS): Service Aspects; Service 

Principles". 

[6] 3G TS 22.05: "Universal Mobile Telecommunications System (UMTS); Services and Service 

Capabilities". 

[7] ITU-T Recommendation Q. 1 70 1 : "Framework for IMT-2000 networks" . 

[8] ITU-T Recommendation Q.171 1: "Network Functional Model for IMT-2000". 

[9] 3G TS 22.00 UMTS phase 1 . 

[10] 3G TS 23.127 "Virtual Home Environment/Open Service Architecture" 

2.2 Informative references 

[1] 3G TR 22.70: "Universal Mobile Telecommunications System (UMTS); Virtual Home 

Environment" . 
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[2] World Wide Web Consortium Composite Capability/Preference Profiles (CC/PP): A user side 

framework for content negotiation (www.w3.org). 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

HE-VASP: Home Environment Value Added Service Provider. This is a VASP that has an agreement with the Home 
Environment to provide services. 

Local Service: service, which can be exclusively provided in the current serving network by a Value added Service 
Provider. 

Service Capabilities: bearers defined by parameters, and/or mechanisms needed to realise services. These are within 
networks and under network control. 

Service Capability Feature: functionality offered by service capabilities that are accessible via the standardised 
application interface. 

Services: services are made up of different service capability features. 

Service Execution Environment: service execution environment is a platform on which an application or programme 
is authorised to perform a number of functionalities; examples of service execution environments are the user 
equipment, integrated circuit card and a network platform or any other server. 

Applications / Clients: these are services, which are designed using service capability features. 

Application Interface: standardised Interface used by application/clients to access service capability features. 

Personal Service Environment: contains personalised information defining how subscribed services are provided and 
presented towards the user. The Personal Service Environment is defined in terms of one or more User Profiles. 

Home Environment: responsible for overall provision of services to users. 

User: is a logical entity, which uses UMTS services. 

User Interface Profile: contains information to present the personalised user interface within the capabilities of the 
terminal and serving network. 

User Services Profile: contains identification of subscriber services, their status and reference to service preferences. 

User Profile: this is a label identifying a combination of one user interface profile, and one user services profile. 

Value Added Service Provider: provides services other than basic telecommunications service for which additional 
charges may be incurred. 

Virtual Home Environment: concept for personal service environment portability across network boundaries and 
between terminals. 

Further UMTS related definitions are given in 3G TS 22.101. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

API Application Programming Interface 

CAMEL Customised Application For Mobile Network Enhanced Logic 

CAP Camel Application Part 

CORBA Common Object Request Broker Architecture 

CSE Camel Service Environment 
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FFS For Further Study 

GSN GPRS Support Nodes 

HE Home Environment 

HE-VASP Home Environment Value Added Service Provider 

HLR Home Location Register 

LCS LoCation Services 

MAP Mobile Application Part 

ME Mobile Equipment 

MExE Mobile Station (Application) Execution Environment 

MMI Man Machine Interface 

MS Mobile Station 

MSC Mobile Switching Centre 

OSA Open Service Architecture 

PLMN Public Land Mobile Network 

PSE Personal Service Environment 

SAT SIM Application Tool-Kit 

SIM Subscriber Identity Module 

SMS Short Message Service 

SSF Service Switching Function 

USIM User Service Identity Module 

USSD Unstructured Supplementary Service Data 

VASP Value Added Service Provider 

VHE Virtual Home Environment 

Further GSM related abbreviations are given in GSM 01.04. Further UMTS related abbreviations are given in UMTS 
TS 22.01. 



General Description of the VHE 



Virtual Home Environment (VHE) is defined as a concept for personal service environment portability across network 
boundaries and between terminals. The concept of the VHE is such that users are consistently presented with the same 
personalised features, User Interface customisation and services in whatever network and whatever terminal (within the 
capabilities of the terminal and network), where ever the user may be located. 

The key requirements of the VHE are to provide a user with a personal service environment which consist of: 

- personalised services; 

- personalised User Interface (within the capabilities of terminals); 

consistent set of services from the user's perspective irrespective of access e.g. (fixed, mobile, wireless etc. 
Global service availability when roaming. 

The standards supporting VHE requirements should be flexible enough such that VHE can be applicable to all types of 
future networks as well as providing a framework for the evolution of existing networks. Additionally the standards 
should have global significance so that user's can avail of their services irrespective of their geographical location. This 
implies that VHE standards should: 

- provide a common access for services in future networks; 
enable the support of VHE by future networks; 

enable the creation of services; 

enable personal service environment to be recoverable (e.g in the case of loss/damage of user equipment). 
Roles and components involved in realisation of VHE consist of the following also see figure 1 : 

- home environment; 
user identifiers; 
users; 
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terminals (simultaneous activation of terminals providing the same service per single subscription is not 
allowed); 

serving networks; 

subscriptions; 

possibly value added service providers; 

personal service environment; 

user profiles. 
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Figure 1 : Service Provisioning From User's point of View 

The Home Environment provides and controls services to the user in a consistent manner. The User's personal service 
environment is a combination of services and personalisation information (described in the user profile). The user may 
have a number of user profiles which enable her to manage communications according to different situations or needs, 
for example being at work, in the car or at home. Services provisioned to the user may allow or require personalisation 
by the user. 

The Home Environment provides services to the user in a managed way, possibly by collaborating with HE-VASPs, but 
this is transparent to the user. The same service could be provided by more than one HE- V ASP and HE-VASP can 
provide more than one service. 

Additionally, but not subject to standardisation, the user may access services directly from Value Added Service 
Providers. The Home Environment does not manage services obtained directly from VASPs. A mechanism may be 
provided which allows the user to automate access to those services obtained directly from VASPs and personalise 
those services. However such a mechanism is outside of the scope of the present document. 



Framework for Services 



The implementation of VHE in UMTS release 99 shall support both GSM phase 2+ release 99 teleservices, bearer 
services and supplementary services as applied in 3G TS 22.100 and new services built by service capability features. 
Later UMTS developments will provide support for a wider range of services in later releases. 
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Figure 2: Framework for Services 

The goal of standardisation in UMTS with respect to services is to provide a framework within which services can be 
created based on standardised service capability features see figures 2 and 3. UMTS services will generally not rely on 
the traditional detailed service engineering (evident for supplementary services in second-generation systems), but 
instead provides services using generic toolkits. 

Services can be built using service capability features ([1], [2], [3], [4], [9], [10]), which are accessed via a standardised 
interface. An example of how a service can be built on service capability features could be "call to nearest restaurant", 
this will make use of call set-up, authorisation, location and database lookup. 

The available service capability features are visible to applications through the standardised application interface. The 
application interface can be realised in a non-generic way (implying applications must have knowledge of the 
underlying mechanisms used) and/or a generic way (implying applications need not have knowledge of underlying 
mechanisms used). The functionality provided in both cases is the same and both solutions are independent of vendor 
specific solution. 

For example, in the non-generic way, the User Location service capability features can be provided by a location server 
(e.g HLR, LCS). In the generic way the application will only see a single User Location service capability feature and 
does not know which location server provides it. 

the standardised application interface shall beTndependent of vendor specific solutions; 

independent of programming languages, operating systems etc used in the service capabilities; 

secure scalable and extensible. 

In the case of realising the standardised application interface in the generic way, the following additional requirements 
apply: 

independent of the location where service capabilities are implemented; 

independent of supported server capabilities in the network; and 

Access to Service Capability Features shall be realised using modern state of the art access technologies, e.g. 
distributed object oriented technique might be considered. 
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5.1 Ways to realise services 

The information contained in this clause is only to aid understanding and is not an extensive list. 

Figure 3 illustrates how the concept of VHE makes use of the standardised application interface and how that fits to the 
service capability features and service capabilities for release 99. Note that the Service Capabilities (SCx) shown below 
are representatives of the different possible capabilities. It is not to be implied as the agreed architecture as this is a 

stage 2 issue. 
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Figure 3: Possible realisation of Framework for Services 

STANDARDISED SERVICES (Supplementary Services, Tele-Services, etc.) are implemented on existing 
GSM/UMTS entities (e.g. HLR , MSC/VLR and terminal) on a vendor specific basis, using standardised interfaces 
(MAP, etc.) for service communication (e.g. downloading of service data). Availability and maintenance of these 
Services is also vendor dependent. 

OPERATOR SPECIFIC SERVICES (OSS) are not standardised and could be implemented at the GSM/UMTS 
entities (e.g. HLR) on a vendor specific basis or using GSM ph 2+ mechanisms (CAMEL, SAT, MExE). These tool-kits 
use standardised interfaces to the underlying network (e.g. CAP, MAP) or use GSM Bearers to transport applications 
and data, for example, from the MexE service environment of SAT server to the MS/SIM. The implementation of these 
operator specific services on the different platforms (CSE, MExE service environment /SAT Server, MSs) is done in a 
completely vendor specific way and uses only proprietary interfaces. 

Other APPLICATIONS are like OSS not standardised. These applications will be implemented using standardised 
interfaces to the Service Capabilities (Bearers, Mechanisms). The functionality offered by the different Service 
Capabilities are defined by Service Capability Features. These Service Capability Features will be standardised and can 
be used by the application designers to build their applications. 

Within the terminals Service Capabilities are accessible via APIs, for example, MExE and SAT APIs, i.e. there will be 
no service capability features within the terminal. 

The terminal can communicate, using GSM/UMTS bearers, with applications in the network via the service capability 
features which may be optionally realised for MExE service environment and SAT-servers. 
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Figure 4 



6 User Requirements of VHE 



The user shall have the possibility to manage services as well as the appearance of the services. It shall be possible for 
the user to: 

- personalise services; 

Personalised User Interface (within the capabilities of terminals); 

access services from any network or terminal subject to network capabilities, terminal capabilities and any 
restrictions imposed by the home environment; 

use services in a consistent manner irrespective of serving network and terminal, within the technical limitations; 

access new services in the Home Environment; 

modify a user profile(for example to include new services) from any location; 

activate or deactivate user services; 

discover which local services are available; 

access local services in a secure manner; 

interrogate current user service and user interface settings; 

select a particular User Profile; 

indicate (on a session by session basis if necessary) to which subscription charges are to be applied to; 

- recover MS resident User Profile information to protect against loss or damage of user equipment. 

Be aware of limitations of services, which may result from different terminals and or serving network capabilities. 



6.1 



Personal Service Environment 



The Personal Service Environment describes how the user wishes to manage and interact with their communications 
services. The PSE is a combination of a list of subscriptions (detailing provisioned services), preferences associated 
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with those services, terminal interface preferences and other information related to the user's experience of the system. 
Within the PSE the user can manage multiple subscriptions e.g. both business and personal, multiple terminal types and 
express location and temporal preferences. The Personal Service Environment is defined in terms of one or more User 
Profiles. 

6.1.1 User Profiles 

A combination of different preferences is described by a User Profile. The user can define one or more User Profiles 
according to their needs. 

Each User Profile consists of two kinds of information: 

interface related information (User Interface Profile); 

services related information (User Services Profile). 
A User Interface Profile consists of the following type of information: 

menu settings, e.g. menu items shown, menu structure, the placement of icons; 

terminal settings, e.g. ringing tone and volume, font type and size, screen and text colour, language, content 
types and sizes accepted; 

network related preferences e.g. language used for announcements, (editor's note: for clarification) 

A User Services Profile consists of the following information: 

a list of services subscribed to and references to Service Preferences for each of those services if applicable. 
Service Preferences could be information such as redirection numbers, redirection conditions, caller screening 
lists, time-of-day variations etc; 

service status (active/deactive). 

The user may define one or more User Interface Profiles and many User Services Profiles, but a given User Profile 
consists of a single combination of these. In this way a user could for example have a different User Profile to suit each 
of the three different terminals she owns. The User Services Profile is the same in each case but the User Interface 
Profile is different to suit the display capabilities of each terminal. User Profiles could also exist which use the same 
User Interface Profile but different User Services Profiles. This might simply imply that business calls are forwarded to 
an answering service when the user leaves the office because a new User Profile is now active. 

Where the user has more than one User Profile the activation of a particular one could be done in the following ways: 

Statically: the user explicit selects one of the User Profiles as the active one; 

- Dynamically: the appropriate User Profile is selected automatically based upon some criteria such as time of day, 
location, terminal used or many other possibilities. 

Each User Profile must have an identity. 

For UMTS Release '99 the information in the User Profiles enables the service capabilities SAT, MExE and CAMEL 
toolkits in R'99 and existing GSM services to support the user's PSE across network boundaries and between different 
terminals. 

It shall be possible for the service capabilities to access the user profile information from the home environment if 
appropriate. 
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6.1 .2 User Profiles and Multiple Subscriptions 

The user may wish to manage more than one subscription in their PSE. This would allow them to have a single USIM 
but specify different preferences for the services provisioned in each subscription. In this case the User Services Profile 
will need to detail all of the services provided per subscription and provide references to the service preferences for 
each service. When initiating a chargeable event the user will need to indicate which subscription the charges should be 
applied to. 



6.1 .3 Management of the user profile 



The user and the home environment may modify the user's characterisation of the Personal Service Environment as 
described in the User Profiles at any time, and changes become effective at the earliest possible opportunity. The home 
environment shall be able to update distributed User Profiles to reflect any user or home environment modification of 
the user's Personal Service Environment. 

The User Profiles may be stored in the Mobile Station (the SIM or the ME), and/or the home environment. The 
information in User Services Profiles is distributed between the home environment and the MS. In the event of 
loss/damage of mobile station (SIM or ME), the User Profiles must be fully recoverable and be used to reconfigure a 
new mobile station. 

Some aspects of the User Profiles such as aspects related to terminal configuration, must be stored in a standardised 
format to support VHE. 

NOTE: To ensure that User Profiles are applicable to as wide a community of terminal and network types as 

possible, existing work on this topic in other standards fora should be considered. One possibility is the 
work of the World Wide Web Consortium on the Composite Capability/Preference Profile [2], 

6. 1 .4 Requirements for Standardisation 

To facilitate the provision of PSE and User Profiles the standard shall: 
uniquely identify User Profiles; 
- provide a standardised format for describing terminal configuration preferences; 



7 Home Environment Requirements for VHE Provision 

It shall be possible for the home environment to: 

control access to services depending on the location of the user, and serving network; 

control access to services on a per user basis e.g subject to subscription; 

control access to services depending on available service capabilities in the serving network, and terminals; 

manage service delivery based on for example end to end capabilities and/or user preferences; 

- request version of specific services supported in serving network and terminal; 

- request details (e.g. protocol versions and API versions) of available service capabilities supported in the serving 
network, and terminals; 

define the scope for management of services by the user, for services provided by the HE; 

handle charging for services (as defined in clause 1 1); 

inform the serving network of the type of charging (i.e. prepaid or/and postpaid) for any required service; 

inform the serving network of the threshold set for a given service required by the user and charged on a prepaid 
account; 

inform the serving network how to manage a service for which the threshold has been reached; 
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manage the prepaid accounts (e.g. increase, decrease the credit, or pass the information to any application which 
manages the credit); 

deploy services to users or groups of users; 

manage provision of services to users or groups of users. 

8 Serving Network Requirements for VHE Provision 

The serving network should not need to be aware of the services offered via the home environment. 

The user/home environment may request capabilities which are necessary to support home environment services. 

It shall be possible for the serving network to perform the following: 

the serving network shall support user access to services in the home environment; 

the serving network shall provide the necessary service capabilities to support the services from the home 
environment as far as possible; 

dynamically provide information on the available service capabilities in the serving network; 

- provide transparent communication between clients and servers in terminals and networks; 

- request the charging information (type of charging, threshold for prepaid services and behaviour if the threshold 
is reached) for any service possibly required by the user; 

handle the call according to the instructions received by the home environment regarding charging activities; 

inform the home environment of the chargeable events (e.g. send CDRs, . . .). 



VASP Relationship to VHE 



The user may access services directly from Value Added Service Providers. Services obtained directly from VASPs are 
not managed by the Home Environment and therefore are not part of the VHE offered by the Home Environment. A 
mechanism should be provided which allows the user to automate access to those services obtained directly from 
VASPs and personalise those services. However such a mechanism is outside of the scope of the present document. 

There may be some information, which is shared between the Home Environment and the HE- VASP (for example 
current capabilities). 

The Home Environment may grant the HE-VASP access to standardised service capabilities in order to allow the 
development and deployment of services on behalf of the Home Environment. 

There are no VASP requirements to support VHE. 



10 Service Capability Features 



Services Capability Features are open, technology independent building blocks accessible via a standardised 
application interface. This interface shall be applicable for a number of different business and applications domains 
(including besides the telecommunication network operators also service provider, third party service providers acting 
as HE- VASPs, etc.). 

All of these businesses have different requirements, ranging from simple telephony and call routing, virtual private 
networks, fully interactive multimedia to using MS based applications. 

The service capability features shall enable applications to make use of the service capabilities (e.g. CAMEL, MExE, 
etc.) of the underlying UMTS network in an open and secure way. 
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Application/Clients access the service capability features via the standardised application interface. This means that a 
single service capability feature is accessible and visible to application/clients via the method/operation invocations in 
the interface. 

Two different types of service capability features can be distinguished: 

Framework service capability feature: this shall provide commonly used utilities, necessary for the non- 
framework service capability features to be accessible, secure, resilient and manageable; 

Non-Framework service capability features: these shall enable the applications to make use of the 
functionality of the underlying network capabilities (e.g. User Location service capability features). 

1 0.1 Framework service capability features 

The framework service capability features will be used e.g. for authentication, authorization, registration, 
notification, etc. and provide functionality that is independent of any particular type of service. Other 
commonly used features are described in more detail within TS 23.127, such as: 

- Trust and Security Management: 

It provides mechanisms for applications and framework to initiate communications, authenticate each other 
and mechanisms for applications to be authorised and access network capability features. 

Integrity Management: 

It provides the support of integrity for both the OS A APIs and the Applications (e.g. load manager, fault 

manager, OAM and Heartbeat manager). 

10.1.1 Authentication service capability feature 

Authentication is used to verify the identity of an entity (user, network, and application). 

Three types of authentication are distinguished: 

User-Network Authentication: before a user can access her subscribed applications, the user has to be 
authenticated by the network that provides access to the application. This allows the network to check to what 
applications the user has subscribed to. User-network authentication is handled within the network and therefore 
outside the scope of the present document. 

- Application-Network Authentication: before an application can use the capabilities from the network, a 
service agreement has to be established between the application and the network. Establishment of such a service 
agreement starts with the mutual authentication between application and network. If a service agreement already 
exists, modification might be needed or a new agreement might supersede the existing. 

User-Application Authentication: before a user can use an application or perform other activities 
(e.g. modifying profile data) the application provider must authenticate the user. When the network already 
authenticates the user, authentication is not needed anymore. When the network is transparent and the user 
accesses an application directly, authentication is needed between user and application but this is outside the 
scope of the present document. 

10.1.2 Authorisation service capability feature 

Authorisation is the activity of determining what an authenticated entity (user, network, and application) is allowed to 
do. 

NOTE: Authentication must therefore precede authorisation. 

Two types of authorisation are distinguished: 

- Application-Network Authorisation: the network verifies what non-framework service capability features s 
(or even some framework service capability feature) the application is allowed to use. Once an application has 
been authorised to use one, more or all (non-framework) service capability features no further authorisation is 
required as long as the "allowed" (non-framework) service capability features are used. 
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User-Application Authorisation: the application verifies what actions the user is allowed to perform 
(e.g. deactivation of functionality, modification of application data). This is transparent to the network and 
therefore outside the scope of the present document. 

10.1 .3 Registration service capability feature 

The Registration service capability feature enables the non-framework service capability features (e.g. User Location) 
to register at the Framework. Registration must take place before authorised applications can find out from the 
Framework which non-framework service capability features are available. This means that the non-framework service 
capability features must be registered before they can be discovered and used by authorised applications. 

Note that only the non-framework service capability features have to be registered. The Framework service capability 
features (defined in subclause 10.1) are available by default since they provide basic mechanisms. 



1 0.1 .4 Discovery service capability feature 



The Discovery service capability feature enables the application to identify the total collection of service capability 
features that it can use. Upon request of the application, the Discovery service capability feature will indicate the non- 
framework service capability features that are available for the application. The list of available service capability 
features is created through the Registration process described in subclause 10.1.3. This means that a service capability 
feature must be registered at the Framework before it can be discovered by the application. 

1 0.1 .5 Notification service capability feature 

The Notification service capability feature allows applications to enable, disable and receive notifications of application 
related events that have occurred in the underlying GSM/UMTS network, e.g. indication that a new call is set-up or a 
message is received. 

NOTE: It should be further studied if Notification is only a Framework service capability feature or also 
specialised as non-framework service capability features (e.g. for notifications on location update, 
disconnected party etc.). 

1 0.2 Non-Framework service capability features 

The Non-Framework service capability features represent the total collection of service capability features that are not 
included in the Framework. These non-framework service capability features enable the application to make use of the 
functionality provided by the network and service capabilities. 

Service capability features shall be defined as much as possible in a generic way to hide the network specific 
implementation. To achieve this, it is necessary to identify the functionality that is provided by more than one service 
capabilities. For example, User Location can be produced in several underlying ways. This functionality can be 
captured once when defined the service capability features in a generic way. It is important that the generic part 
becomes as large as possible. 

When applications use the generic service capability features, these applications become independent of (portable over) 
underlying service capabilities. Applications shall however still be able to request service capability features specific to 
a service capability (e.g. Call Setup from CAMEL). This will increase dependency of the used service capability. 

The following subclauses define generic service capability features e.g. for Session Control and Message Transfer. 

1 0.2.1 Session Control service capability features 

This subclause details the Session Control related service capability features. Session Control service capability 
features shall offer the functionality to establish, maintain, modify and release bearers to/from other parties or entities. 

Herein, the term "session" can mean anything from a simple voice call to a complex multimedia "call" (including 
exchange of non delay-sensitive data). To define the necessary service capability features it is proposed to use a generic 
model (including the "session party handling"). 

For example, the following Session Control service capability features shall be provided (the list is not exhaustive): 
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allow the session to continue with modified information (e.g. changed destination number); 

- release the session (i.e. removing all parties from the session); 

- request session information (i.e. information like session duration, session end time); 

supervise session (e.g. monitor for session duration or data volume, tariff switching moments and changes in 
QoS); 

- presentation of, or restriction of, information associated with a party involved in a session (e.g. calling line ID, 
calling name); 

collect information from user (i.e the application shall be able to request data from the user. For example, the 
user might enter some code number). 

For each session it shall be possible to specify: 

the events on which monitoring is required ([3]). 

NOTE: The mapping to service capabilities is for further study (it shall be investigated to which extend the 
requirements above fit to CAMEL, MEXE and other service capabilities). 

1 0.2.2 Security/Privacy service capability features 

For the Security/Privacy the following service capability features shall be supported: 
encryption of user data and signalling. 

10.2.3 (Void) 

1 0.2.4 User Location service capability features 

The User Location service capability features provide an application with information concerning the user's location. 

The user location information contains the following attributes: 

location (e.g. in terms of universal latitude and longitude co-ordinates); 

accuracy (value depending on local regulatory requirements and level of support in serving/home networks; 
note that the accuracy of the serving network might differ from that in the home environment); 

age of location information (last known date/time made available in GMT). 

The following service capability features shall be provided: 

- report of location information: 

the application shall be able to request user location information; 

- by default the location information is provided once; the application may also request periodic location 
reporting (i.e. multiple reports spread over a period of time). 

- notification of location update: 

the application shall be able to request to be notified when the user's location changes, i.e. when: 

the user enters or leaves a specified geographic area; 

the user's location changes more than a specified lower boundary. The lower boundary can be selected 
from the options provided by the network. 

The application shall be able for each user to start/stop receipt of notifications and to modify the required accuracy by 
selecting another option from the network provided options. 

- Access control to location information: 
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- the user shall be able to restrict/allow access to the location information. The restriction can be overridden by 
the network operator when appropriate (e.g. emergency calls). 

1 0.2.5 User Status service capability features 

The User Status service capability features enable an application to retrieve the user's status, i.e. to find out on which 
terminals the user is available. 

The following service capability features shall be provided: 

- retrieval of User Status: 

the application shall be able to retrieve the status of the user. 

- notification of User Status Change: 

the application shall receive notifications when the user's terminal attaches or detaches: 

detach: the user's terminal is switched on or the network initiates detach upon location update failure; 

attach: the user's terminal is switched on or there has been a successful location update after network 
initiated detach. 

The application shall be able for each terminal to start/stop receipt of notifications. 

1 0.2.6 Terminal Capabilities service capability features 

The Terminal Capabilities service capability features enable the application to find out what capabilities the user's 
terminal supports (note: "terminal" covers both (mobile) equipment and USIM). 

The following service capability features shall be provided: 

- retrieval of Terminal Capabilities: 

the application shall be able to retrieve the capabilities of the terminal. This includes: 

the media that the terminal is capable to deal with (e.g. audio, video, PC data, WAP data; this information 
is needed by the application e.g. when the user wants to download messages from the mailbox); 

the number of calls that the terminal can deal with simultaneously. 

Note: In Release 99 Terminal Capabilities can be provided by the Terminal Capability SCF only if the terminal 
is capable to supply them. 

Terminals (e.g. MEXE-, WAP clients) may provide their Terminal Capabilities to the server (e.g. MEXE service 
environment or WAP gateway) either spontaneously or on request. 

1 0.2.7 Information Transfer service capability features 

The Information Transfer service capability feature shall enable an application to indicate to a user respectively an 
application in the UE or USIM about the presence of existing information for her. Physically, this indication may be 
sent by the underlying network e.g. as a SMS or USSD message to the terminal. The Information Transfer service 
capability feature provides the means to inform the underlying network that an indication shall be sent to the user. 

NOTE: For UMTS release 99 mechanisms like USSD or SMS may be employed to transfer the indication to the 
users terminal. 

The following service capability feature shall be supported: 

- send information notification: 

the Send information notification service capability feature provides the means to inform the underlying 
network that an indication shall be sent to a user respectively an application in the UE or USIM about the 
presence of existing information for her; 
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this indication shall contain sufficient information for the receiving entity to react in an appropriate manner, 
e.g. an announcement ID, URL, a string, etc. In addition the application or execution environment in the 
terminal (e.g. MExE SAT), that is to display this information, needs to be referenced. 

- request message receipt notification: 

the application can request to receive a notification every time a message is received in the mailbox for the 
user. This allows the application to take the appropriate action, e.g. informing the user. 

10.2.8 Reserved section 

1 0.2.9 User Profile Management service capability features 

The User Profile Management service capability features allow the application to retrieve the user profile (see 
subclause 6.1 for more information on user profiles). 

For release 99 the following information could be retrieved by an application: 

terminal capabilities, as described in the proper section, 

user information provided by and limited to CAMEL 3 R99 functionalities (ATI, ATN, ATM). 

10.2.10 Charging service capability features 

The Charging service capability features enable the application to instruct the network and inform the user with 
charging information and to add some additional charging information to the network generated Call Detail Records. 

The following service capability features shall be provided: 

define and manage the threshold (e.g. session duration, data volume) for the required service; 

send charging data (this data is included in a "free format" field in the network generated Call Detail Records. It 
may contain information like a application generated Call Id, used by the application provider to relate 
application generated charging information to the network generated charging information); 

transfer of Advice of Charge data (as defined in GSM02.24) to the terminal. 



1 1 Service execution environment 

The following service execution environments shall be standardised and could be used to provide a VHE for the user: 

- user equipment execution environment; 
IC card execution environment; 

network execution environment not required for R99. 
For UMTS release 99 one or more of the following shall provide the execution environments: 

- MExE; 

- SIM Application Tool kit (SAT); 

- CAMEL. 

12 Charging requirements 

Services, which are provided as part of the VHE, may be subject to charge at the discretion of the home environment 
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There are several forms of charging which shall be available to the home environment. It shall be possible for the home 
environment to charge in the following instances: 

subscription: 

the user's registration to use services may be subject to charge, 
service transfer: 

the transfer of services and/or information to the user MS or USIM may be subject to charge. 

service upgrading: 

the upgrading of previously transferred services to the user's MS or USIM may be subject to charge 
(automated upgrading of services may be subject to a different charge). 

service usage: 

the usage of services by a user may be subject to a charge. 

- roaming: 

the usage of VHE services when roaming may be subject to additional charges. 

Refer to UMTS 22.15 for further details. 

Other charging requirements may be identified and are for FFS. 

1 3 Security requirements 

The mechanisms supporting VHE shall maintain a secure environment for the user and home environment. 
The specific security requirements are FFS . 
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Annex A (informative): 

Service examples to be considered in VHE 

The following table shows the service examples to be considered in VHE. 

Table A.1 



Benchmark Services 


Abb 


Priority 


Abbreviated Dialling 


ABD 


A 


Account Card Calling 


ACC 


B 


Automatic Alternative Billing 


AAB 


A 


Call Distribution 


CD 


A 


Call Forwarding 


CF 


A 


Call Hold 


CH 


A 


Call Rerouting Distribution 


CRD 


A 


Call Transfer 


TRA 


A 


Call Waiting 


CW 


A 


Completion of Call to Busy Subscriber 


CCBS 


A 


Conference Calling 


CON 


A 


Credit Card Calling 


CCC 


B 


Destination Call Routing 


DCR 


A 


Follow-Me Diversion 


FMD 


A 


Freephone 


FPH 


A 


Global Virtual Network Service 


GVNS 


A 


Hot Line 


HOT 


A 


International Telecommunication Charge Card 


ITCC 


B 


Internetwork Freephone 


IFPH 


A 


Internetwork Mass Calling 


I MAS 


A 


Internetwork Premium Rate 


IPRM 


A 


Internetwork Televoting 


IVOT 


A 


Malicious Call Identification 


MCID 


A 


Mass Calling 


MAS 


A 


Message store and forward 


MSF 


A 


Multimedia 


MMD 


B 


Originating Call Screening 


OCS 


A 


Premium Rate 


PRM 


A 


Security Screening 


SEC 


A 


Selective Call Forward on Busy / Donf answer 


SCF 


A 


Split Charging 


SPL 


A 


Televoting 


VOT 


A 


Terminating Call Screening 


TCS 


A 


Terminating Key Code Protection 


TCKP 


B 


Universal Access Number 


UAN 


B 


Universal Personal Telecommunication 


UPT 


A 


User-Defined Routing 


UDR 


B (FFS) 


Virtual Private Network 


VPN 


A 



Benchmark services listed above could be realised by service capability features. 
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Annex B (informative); 
Change history 



Version 


Date 


Comment 


0.0.0 


Sep 1 998 


Initial Draft at Ipswich 


0.1.0 


Oct 1998 


Initial Draft at Uxbridge Meeting 


0.2.0 


Nov 1998 


Draft at Newbury Meeting 


0.3.0 


Jan 1999 


Draft after Stockholm meeting 


0.4.0 


Jan 1999 


Draft to include requirement for R99 


0.5.0 


Feb 1999 


Draft to include corrections from Ericsson and TTC requirements 


0.6.0 


Feb 1999 


Draft to include changes made after adhoc meeting in Vienna 


0.7.0 


March 1999 


Change to include text to fig 2 and 3 and for presentation to v1 .0 


1.0.0 


March 12/99 


Input text to state the inclusion of OSA requirements 


1.1.0 


March 17/99 


Addition of Annex B, OSA text 


1.2.0 


April 30/99 


Modification after Dublin Meeting 


1.3.0 


May 19/99 


Modification after Hampton CT. 


2.0.0 


June 99 


Modification at Sophia Antipolis 


3.0.0 


June 99 


Approved Specification at SA#4 in Miami 


3.1.0 


October 1999 


Inclusion of 3 CRs at SA#5, Kyongju, Korea 


3.2.0 


March 2000 


Inclusion of CRs at SA#7, Madrid, Spain 









TSG SA# 


SA Doc. 


SA1 Doc 


Spec 


CR 


Rev 


Rel 


Cat 


Subject/Comment 


Old 


New 


SA#04 






22.121 














3.0.0 


SP-05 


SP-99442 


S1 -99809 


22.121 


002 




R99 


B 


Virtual Home Environment. 


3.0.0 


3.1.0 


SP-05 


SP-99442 


S1 -99845 


22.121 


003 




R99 


B 


Addition of IP4 Addressing 


3.0.0 


3.1.0 


SP-05 


SP-99442 


S1 -99535 


22.121 


004 




R99 


B 


Charging capabilities 


3.0.0 


3.1.0 


SP-07 


SP-000067 


S1 -0001 07 


22.121 


005 




R99 


F 


Clarification of service capabilities 


3.1.0 


3.2.0 


SP-07 


SP-000067 


S1 -0001 56 


22.121 


006 




R99 


C 


Information Transfer service capability 
feature 


3.1.0 


3.2.0 


SP-08 


SP-000204 


S1 -000267 


22.121 


007 




R99 


F 


Modification of section 10.2.6 on reducing 
the scope of the VHE/OSA reqirements 


3.2.0 


3.3.0 


SP-08 


SP-000204 


S1 -000283 


22.121 


008 




R99 


F 


Removal of section 1 0.2.3 Address 
Translation SCF 


3.2.0 


3.3.0 


SP-08 


SP-000204 


S1 -000285 


22.121 


009 




R99 


F 


Modification of section 10.2.9 to reduce 
scope of User Profile Management service 
capabilities 


3.2.0 


3.3.0 


SP-08 


SP-000204 


S1 -000334 


22.121 


010 




R99 


F 


Alignment of VHE Stage 1 top VHE/OSA 
Stage 2 and stage 3 


3.2.0 


3.3.0 
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